
-------- TML Message #286 --------

Subject: STAR SYSTEM DIGEST, Volume 1
Date: 05 Apr 89 17:02:36 PDT (Wed)
From: jamesp
Archive-Message-Number: 286



***************************************************************************
** STAR SYSTEM DIGEST: star system generation, storage, and display.	 **
** All followups on this topic should be sent to morrison@pyr.gatech.edu **
** They will be edited for clarity and resent to the Traveller Mailing	 **
** List in a following digest.						 **
***************************************************************************

Subjects in today's digest:
	Welcome
	Correspondence between Fred Schiff, James Perkins, Rob Miracle

- --------

From: James T. Perkins <jamesp@dadla.la.tek.com>
Subject: Welcome

Welcome to the TML Star System Digest.  A few weeks ago I asked if
someone on the list was interested in being "Topic Coordinator" for the
topic of Star System Database issues.  BILL MORRISON
(morrison@pyr.gatech.edu) jumped at the challenge and offered to be
Topic Coordinator for this issue.  Let's all give Bill a warm welcome
for offering to devote some of his free time to this task.

Bill will collect your input on the topic of Star System Databases,
their generation, storage, and display.  He will collect the letters,
edit them for brevity and clarity, and combine them into digests.  He
will then send the digests to the entire Traveller Mailing List.  He
will try to recommend areas where further discussion is needed and try
to bring the people offering discussion into agreement.

Those of you uninterested in the topic will be able to quickly recognize
and delete the digests, and your mail traffic will not be greatly
increased, due to the digesting.

The topic of star system generation, storage, and interchange has been a
hot topic.  The following is the first digest, which I have done for
Bill as an example.  I have also prepared the second digest, which
summarizes the correspondence in this note.  Bill will start collecting
your input for digest volume 3 immediately.

Again, thanks to Bill for the commitment!  With help like this we can
really get things accomplished.

- --------

From: Fred Schiff <vu0141@bingvaxu.cc.binghamton.edu>
Subject: Correspondence between Fred Schiff and James Perkins

The following is my archive of most of my e-mail with James Perkins on
the gensec program and the issue of how to databasize MegaTraveler
system generation.  [... this is a digest WITHIN a digest -- James ...]

- --

To: vu0141@BINGVAXU.CC.BINGHAMTON.EDU
Subject: Coding Styles and Trade Routes
From: "James T. Perkins" <jamesp%dadla.la.tek.com@RELAY.CS.NET>

> I'm going to do a little something with the programs. I like your code
> much better than the longer one in bundle 10.  You write much cleaner
> C code (of course the programs do different things, but your code is
> much nicer-- course on a good day I can *read* C :)  I see there being
> two ways to go with these things: either a bunch of little programs,
> possibly designed as filters, each with its own job, or one huge data-base
> management system with all the sectors/worlds/output formats, etc. Ugh.

Do "something", huh?  Are you like me and just SAY you're going to do
something, then never find time, or are you really going to DO something about
them :-).  (Just teasing you).

You have completely and totally flattered me on my coding style.  All those
programs were icky hacks.  Someone wrote me once and said, "can you covert
this program into Pascal?"  I had to write them back and tell them I couldn't,
for one I can't remember my Pascal anymore, for two I'm so used to hacking
stuff with pointers and weak type checking that I didn't want to take the time
to think through the problem and design a solution.

And to think I get paid for producing maintainable, well-documented software.
Sheesh! :-)  At least I try to avoid "hacking" in my work software.

I agree with your ideas on approaches.  With either scheme, I get lost due to
the volume and multiple layers of detail inherent in the system
(galaxy/quadrant/sector/subsector/system/star/orbit/
planet-belt/moon/planet-map/region-map/local-map).

> Are there any programs about which deal with X-boat (& trade) routes?

None that I am aware of.  You could come up with some interesting algorithms
though.  One old, simple algorithm that came in the ORIGINAL Traveller boxed
set (I MEAN early editions) was as follows:

                        JUMP ROUTES

        World   ------- Jump  Distance -------
        Pair    Jump-1  Jump-2  Jump-3  Jump-4
        A-A     1       2       4       5
        A-B     1       3       4       5
        A-C     1       4       6       -
        A-D     1       5       -       -
        A-E     2       -       -       -
        B-B     1       3       4       6
        B-C     2       4       6       -
        B-D     3       6       -       -
        B-E     4       -       -       -
        C-C     3       6       -       -
        C-D     4       -       -       -
        C-E     4       -       -       -
        D-D     4       -       -       -
        D-E     5       -       -       -
        E-E     6       -       -       -

        Copyright 1977 Game Designer's Workshop
        Traveller, Volume 3, Worlds and Adventures, p. 2.

The idea is that you have to roll or exceed the indicated number on a D6
for a jump (aka trade) route to exist.

Apparently this chart did not survive revisions of the Traveller rules.
I found that it produced some interesting graphs, but did not work as
well when you changed the chance of system presence or the starport
class generation table -- either you got overrun with trade routes, or
areas became isolated too much.  I finally adopted use of this chart as
an indication, and would use its results with much adjustment.

Probably the best way to assign trade routes would be an adjustment of
the above chart including system density, starport likelihood, and
especially trade classes for the worlds (Agricultural-NonAgricultural
routes have higher likelihood, whereas Agricultural-Agricultural routes
have lower likelihood, and HiPop worlds have higher chance of
connectivity than LoPop worlds).

As for X-Boat routes I have no fully- or half-baked ideas.  As a
quarter-baked idea I'd suggest developing an adaptive algorithm which
takes into account the locality of high-quality starports, subsector and
subsector capitols, scout bases, and the standard rules (like: Xboat
routes usually pass through major starports or within 4 parsecs) to
generate them.

Hmmm.  Maybe I should extract this and send it to the list to generate some
discussion...  what do you think?

- --

To: James Perkins
Subject: RE: Coding Styles and Trade Routes
From: Fred Schiff

>Do "something", huh?  Are you like me and just SAY you're going to do
>something, then never find time, or are you really going to DO something about
>them :-).  (Just teasing you).

Oh come on, all I haveto do is find a stupid C compiler when I go home
for Spring break on my father's PC. (Nice being a student, occasionaly
they let us leave the asylum.)  "One of these days..." One of these days
I'm going to have to learn sufficient C to be confident with it. The
Traveller flow-charts have all these little DMs and using a stupid macro
would not have occurred to me. The differnce between a seasoned professional,
I imagine. (:-) The stargen program is long, has no comments and does use
those stupid damm pointers; your stuff is small and a least I can read the
stupid thing. Elegance. Ah, always elegenace. This is a hack?

Its nice to have lots of little programs all dealing with a text file
containing the sector info. But its sort of limited. Where do I put the
rooutes that ships go through. (Deciding which trade routes are reasoble
is a separate and less interesting problem actually--in the case of war
or invasion or genreral chaos I think I'd just like to know *all* the
various routes through the star-lanes. Maybe the commerical ones don't
follow X-boats lines. Maybe thats important. etc) The sector and subsector
names aren't even listed. How do I deal with it when I want an extended
generation for a star system (I don't have too do that for every star, just
the ones I want to deal wwith) Last, how do the sectors fit together?
Certainly thats not a big problem, since you are only dealing with one at
a time usually, but wouldn't it be nice.

I have a copy of Traveler's Digest. (I mean the one published on Earth :-)
and they have these beautiful maps of subsectors showing bases and X-boat
routes and sector maps with the routes and star systems and capitals
diagrammed. Pretty. OK, no one needs this much. But it would be nice to
have this all in a database at me fingertips.

Umph. Could use grid files, but since the maps aren't really maps, but
diagrams of locations that might be wasteful. The routes could be done
in two files containing the edges and vertices of the graph. (Then you
could write "whats the fastest/most scenic route to Core" programs)
Each star system could have an optional text field for a paragraph of
info, optional extended, optional Grand Census/Grand Survey if more than
the UPP is needed. World maps would be separate, but its supposed to be
a DBMS so it would deal with lots of files. Would need to convert
from/to sector files.

Thinking out loud. No I can't do even a fraction of this, but a more
complete world generator attached to more than a straight text file
would be nice.

- --

To: Fred Schiff
Subject: Re: Coding Styles and Trade Routes
From: "James T. Perkins" <jamesp%dadla.la.tek.com@RELAY.CS.NET>

> Oh come on, all I haveto do is find a stupid C compiler when I go home
> for Spring break on my father's PC. (Nice being a student, occasionaly
> they let us leave the asylum.)  "One of these days..." One of these days

You mean you actually have a week of FREE TIME?!?!  Amazing concept! :-)

> I'm going to have to learn sufficient C to be confident with it. The
> Traveller flow-charts have all these little DMs and using a stupid macro
> would not have occurred to me. The differnce between a seasoned professional,
> I imagine. (:-) The stargen program is long, has no comments and does use
> those stupid damm pointers; your stuff is small and a least I can read the
> stupid thing. Elegance. Ah, always elegenace. This is a hack?

But you've got to use pointers for anything complex, to get it to be
manageable.  Plus I have the feeling that Waddell and Co. (the stargen stuff)
stripped the comments out prior to  source release, to keep people from
actually being able to understand the source.

> Its nice to have lots of little programs all dealing with a text file
> containing the sector info. But its sort of limited. Where do I put the
> rooutes that ships go through. (Deciding which trade routes are reasoble
> is a separate and less interesting problem actually--in the case of war
> or invasion or genreral chaos I think I'd just like to know *all* the
> various routes through the star-lanes. Maybe the commerical ones don't

Ah... now you're exactly where I've been at; how to manage all this data.

> follow X-boats lines. Maybe thats important. etc) The sector and subsector
> names aren't even listed. How do I deal with it when I want an extended
> generation for a star system (I don't have too do that for every star, just
> the ones I want to deal wwith) Last, how do the sectors fit together?
> Certainly thats not a big problem, since you are only dealing with one at
> a time usually, but wouldn't it be nice.

Yeah, I've put a little thought into all these.

> I have a copy of Traveler's Digest. (I mean the one published on Earth :-)
> and they have these beautiful maps of subsectors showing bases and X-boat
> routes and sector maps with the routes and star systems and capitals
> diagrammed. Pretty. OK, no one needs this much. But it would be nice to
> have this all in a database at me fingertips.

Yes, it would be, but how to display it on the terminal; at the different
scales, etc.

> Umph. Could use grid files, but since the maps aren't really maps, but
> diagrams of locations that might be wasteful. The routes could be done

I tend to think so.

> in two files containing the edges and vertices of the graph. (Then you
> could write "whats the fastest/most scenic route to Core" programs)
> Each star system could have an optional text field for a paragraph of
> info, optional extended, optional Grand Census/Grand Survey if more than

Paragraph of info?  Heck, I figure if someone wants to get verbose about
anything they should be able to put a whole file of info in on anything.
That's why I think you should be able to comment any sort of object (Sector,
Subsector, System, Star, Planet, Moon, Etc.)

> the UPP is needed. World maps would be separate, but its supposed to be
> a DBMS so it would deal with lots of files. Would need to convert
> from/to sector files.

Yeah, world maps would be optional, in fact I think you should be able
to fill stuff out from the top down.  Oh, you want to look at THIS
subsector? Quick... generate all the systems in it, stow it away.  And
you want to look at THIS system's extended generation stuff? Quick,
generate the expanded system data, stow it away.  Oh, a world map, QUICK,
generate a world map at the grainy level.  This region?  Quick, generate a
regional map... etc.

> Thinking out loud. No I can't do even a fraction of this, but a more
> complete world generator attached to more than a straight text file
> would be nice.

Yes.  But Organization! And representation, both internal and external?
(I go for ascii external representations; then you can trade 'em with
your friend on an ABC running XYZ).

- --

To: James Perkins
Subject: Gensec and Mapsub
From: Fred Schiff

Hello. I'm back.

I *did* do some work on your programs.  Basically I changed the output
format and made it compatible with Megatraveler.  Minor changes were
made in Mapsub; it prints CAPITOL if it finds the code 'Cx' for a
sector capitol, and capitalizes the name if it is a 'Hi' population
world.

More changes were made in Gensec.  Trade codes have the second letter lower
case, pop multiplier, gas giants and planetary belts appear as numbers.
Some of your code was not correct with the new rules (for example tech
codes go up to 20) and I found a genuine bug! It should be <= rather than
< in the percentage; in testing the program I was getting no systems with
a stellar density of 1%. (A feature, its a feature!) I changed the format
around a bit, putting the system name first.

I made some changes in the options.  I was going to allow you to specify that
you wanted a random name rather than "Unnamed" but couldn't decide if it was
necessary.  You can generate an entire sector or just a specified subsector.
And you can specify stellar density with a number (as before) or with the
words "rift", "dense" etc.  You can also with words specify the sector's
maturity (which alters the spaceport present)

Hacking C was kind of fun.  Pretty good for a guy without a C book! As I don't
have a C book and I took out your copywrite notice I'm sending you the programs
to take a look over and then post. Just make sure you spell my name Rite! [sic]

I took a stab at the extended generation system.  I didn't finish because it is
a long program and I had work to do.  I somehow misplaced the file system.c (no
big deal, I can't stand these guys code). I've taken out things which were not
in Megatraveller (I can only digest so much at a time) so albedo, surface temp.
etc. are all out.  I put in comments, re-wrote some of it a little nicer and
looked at the Ref Manual to make sure they were doing things correctly. I stole
your limit and DM macros because you should try to make programs easier to
understand rather than harder.  If I get back to this I'll send it over to you;
I have changed it so that it does not do mainworld generation. It takes a file
in the same format as mapsub (extracted from a sector file perhaps) and does
the extended processing on each mainworld.  At least thats how its supposed to
work.  I didn't see the point of doing Extended generation on an entire galaxy,
figuring that you'd only want to do it on those systems you were interested in.

Concerning the database thing: not a complete solution, but how about, for
every system you have 3 files:
  name.sector (mainworld generated sector info)
  name.xboats (xboats routes in sector name)
  name.extend (additional info on world I'm interested in)

the last would have lines with *Subsector name-of-subsector, after which
information on worlds in that subsector would be listed. Each world would
be introduced by a delimiter of *World name & UWP of world followed by whatever
info you decided to place there.  That info could be a small paragraph or the
extended generation info, or a page of info, or some encounter tables, and a
couple of pages of info, whatever.  This makes it a text database and thus
portable, requiring only a search function to find the world you want. If there
wasn't anymore information known about the world except that found in the
sector list the world would not have to be listed. What do you think?

- --

To: Fred Schiff
Subject: Re: Gensec and Mapsub
From: "James T. Perkins" <jamesp%dadla.la.tek.com@RELAY.CS.NET>

My, you have been busy.  I appreciate all the work you went to to adjust
my programs for MT.  I think I'll hack them into my coding style and
re-release them.  I'll keep the old ones around for those people
uninterested in MT.

I like the idea of having three files for the sector, and I think your
approach might just work: one file for UWP's, one file for routes, and
one file for extension information.

One thing we want to be careful to avoid is duplicating information.  We
should try to work out a single "Key" data item.  For the systems, for
example, we have the hex id.  So now I come to this idea:

        Name.sector     Sector name, Subsector names, and all system UWP's
        Name.routes     Xboat, trade, and other routes
        Name.extend     Textual extra information on Sector, Subsectors, and
                        systems.

The Name.sector file is organized as follows:

        #Sector: Spinward Marches
        #Subsector_A: Chronor
        Zeycude         0101 C330698-9 A Na Ni Po De    613Zh M9 V
        Reno            0102...
        Errere          0103...
        Cantrel         0104...
        Gyomar          0108...
        ...
        #Subsector_B: Jewell
        #Subsector_C: Regina
        ...
        #Subsector_P: Trin's Veil
        ...

The "#" lines are comments, unless everything up to the first leading
whitespace matches a "magic pattern", like "#Sector:" or
"#Subsector_B:".

The Name.routes file is organized as follows:

        #Route: Xboat
        # Zhodani Xboat Routes
        0103 0304 0303
        0412 0614 0712 0610 0608 0307 0304 0705 0904 1103 1402
        # Darrian Confederation Xboat Routes
        0421 0223 0325 0426 0527 0727
        0325 0624 0724
        ...
        #Route: Megacorporation
        # Oberlindes Lines (Starts at Regina)
        1910 1912 1815 ...
        ...
        #Route: Free Trader Routes
        # Tureded and vicinity
        2414 2514

Here the magic pattern is "#Route:".

Note that rather than having pairs of connected systems, we have a "run"
of connected systems, which avoids a lot of repetition when there is no
branching.  There is nothing to stop you from listing everything as
pairs, though, and this is probably what automatic software generation
will do.

The Name.extend file would be something like this:

        #Sector
        The Spinward Marches...
        ...
        #Subsector_A
        The Chronor Subsector is the home of the Zhodani, who...
        ...
        #System_0101
        The Zeycude system is organized as follows...
        ...
        and here are some world maps...
        ...

If there is browsing software, it will use the magic code fields to
correlate data with the Name.sector file and the name.route file.

Well, what do you think? Shall we call a committee with the rest of the
list? I like your ideas.

We also need to talk about clever programs which operate on the data.
I can think of lots of programs to emit postscript:

        sector2ps - Sector map of systems, ala the Spinward Marches map
        routes2ps - Sector map transparency overlay for each kind of trade route
        extend2ps - Program to format extended information pages

You'd use the above to create pages for a 3-ring binder, for example.

Browsing programs (ascii output):

        showsub - show a subsector map
        showsys - show UWP of system and expansion data
        showsysroutes - show map of vicinity around a system with routes

As well as programs which do generation:

        gensec - generates sectors
        namesec - replaces "Unnamed" on everything with random names
        expandsys - generates expanded data for a system, adds into name.expand
        genroutes - generate automatic routes
        annosys, annosub, annosec - add anotation text to the .expand file

Maybe one big master program that gives you different windows onto the
data, allows selections and operations via a graphics interface on a Mac
or Sun.

So, would you like me to send system.c back to you?

- --

To: James Perkins
Subject: Re: Gensec and Mapsub
From: Fred Schiff

I like your ideas completely.  Which are actually my ideas, except I
communicated telepathically to you to write them out so nice. (Ah elegeance,
elegance, again a big :-;)

I suppose it is about time to take them to committee. I leave in your capable
hands both editing my C hacks and forming something to say to the list.

A few points first: (but you were expecting that)

You gave the UWP in the same format as GDW does, with alignment immediately
after the three data numbers and stars after. I guess this is ok, even if
I don't care for it, as it is necessary to be compatible with what has gone
before, besides which I can always filter the damm things out on my browsing
programs. Of course, gensec must now generate the stars in a system.

Xboat routes: How do you indicate that a route goes off the area of the map?

Putting keys into the files makes things a little more difficult; gensec
now has to check if the file already exists and go in & read it in before
placing info for a subsector. Of course there are other ways to arrange
things, but it all gets a little more messy for these programs; they can
no longer just filter a file but do some processing on it. (poorly stated
and not too important, but I think you get the idea)

Free form data base: a general rule is that you shouldn't make things with
fixed fields.  This is important since, for example, the trade codes will
probably be kind of long; besides the trade codes there are about a dozen
odd things that can be put in there. So do we but delimeters into the
mainworld info or do we write things in such a way that they are parsed
correctly? (This depends on a certain extend as to how long the trade
field is.)

Agreement on non-redundancy of info in separate files.

Will extended system information require a special data format the way
basic generation does?

?World maps? in the extended file? Ah, one of your dreams...but how?

Have you seen Traveller's Digest?  They print subsector maps that are also
a good format for output.

The routine 'upstr' is missing from mapsub and bzero is declared twice in
gensec. (My compiler didn't have it--stupid PC software.)

I don't need the file system.c.  I printed out the whole thing before
breaking it into little pieces, and I don't like their code anyway.

- --

To: Fred Schiff
Subject: Re: Gensec and Mapsub
From: "James T. Perkins" <jamesp%dadla.la.tek.com@RELAY.CS.NET>

> I like your ideas completely.  Which are actually my ideas, except I
> communicated telepathically to you to write them out so nice. (Ah elegeance,
> elegance, again a big :-;)

Oh, well, credit deserves to go where credit is due; I just took your
ideas and re-explained them in a way I could understand and grok.
They're still 95% your ideas.  By adding my own I intend to reduce that
percentage :-).

> I suppose it is about time to take them to committee. I leave in your capable
> hands both editing my C hacks and forming something to say to the list.

Since you already hinted at the idea, I suppose I shall follow up.  BUT
if I could, I'd like to get you to drive the discussion.  Seems I get a
lot of mail already :-).  If you can't, for some reason, I suppose the
discussion will continue, albeit at a slower pace.  I good place to start
would be to digest the messages we've already started with.

BTW, I took your latest version of gensec and mapsub and hacked on them
a little.  I think they're ready to distribute.  I just wanted to get
your agreement that your additions count as a "derivative work", and
that they are still subject to my copyright.  As a result I added back
in all the copyright information.  Before I redistributed them, I wanted
to make sure this settles well with you.  Your contributions to the
program are duly cited in the source comments.

I'm also going to maintain both versions; the new ones are fully
compatible with MT, and mostly compatible with old Traveller, so both
should remain available.

> A few points first: (but you were expecting that)

> You gave the UWP in the same format as GDW does, with alignment immediately
> after the three data numbers and stars after. I guess this is ok, even if
> I don't care for it, as it is necessary to be compatible with what has gone
> before, besides which I can always filter the damm things out on my browsing
> programs. Of course, gensec must now generate the stars in a system.

I just got it from the interim version of gensec.  I have no qualms of
starting a new (saner) format.  I have no reason why I would insist
having stars listed in the UWP, aside from compatibility (which I feel
is sometimes a good thing).

> Xboat routes: How do you indicate that a route goes off the area of the map?

I haven't thought it through yet.  Maybe a code of "OFF" is close
enough.  I suppose one could indicate which hex in an adjoining sector
is the corresponding one; that could work correctly, given that jumps
are always 4 pc or less.

> Putting keys into the files makes things a little more difficult; gensec
> now has to check if the file already exists and go in & read it in before
> placing info for a subsector. Of course there are other ways to arrange
> things, but it all gets a little more messy for these programs; they can
> no longer just filter a file but do some processing on it. (poorly stated
> and not too important, but I think you get the idea)

The keys allow us to simply cross-reference the data with a program.
The keys we are using are:

        Sector name (all related files begin with the sector name)
        Subsector letter (A..P, used in the .sector and .expand)
        World hexid (0101..3240, used in .sector, .expand, and .routes)

I'm trying to keep real, useful, and complete information in each file.
Thus, everything necessary for basic generation is in .sector, including
all standard sector mapping info.  All route information is additional
information, and resides in .routes.  Similarly, textual discussion,
expansion data, and whatnot are listed in .expand.

My understanding is that the .expand contains textual information that
is basically commentary; it isn't used by any program, it is just
displayed as needed.

Maybe we should have .expand for expansion data, and .text for textual
data.  Hmmm... why not .map for map data, too.  Keep all this modular,
and indexed by system hexid.  Then approriate output filters need only
look at files they are interested in.

        .sector - UWP's, sector, subsector, and system names
        .routes - trade, xboat, other routes
        .expand - expanded system data for systems
        .text - commentary on sector, subsector, systems, worlds
        .map - world map information for individual worlds

We'll need a program to generate .sector, then from .sector generate
.routes, .expand, .maps seperately.  And a program to add/edit text
commentary.  And a master menu program? This could get really big.  Now
what format to generate/store the data in? Should be field-independant,
I suppose.  Maybe something like termcap? Yech! Gotta get something better.

> Free form data base: a general rule is that you shouldn't make things with
> fixed fields.  This is important since, for example, the trade codes will
> probably be kind of long; besides the trade codes there are about a dozen
> odd things that can be put in there. So do we but delimeters into the
> mainworld info or do we write things in such a way that they are parsed
> correctly? (This depends on a certain extend as to how long the trade
> field is.)

Ah, yes.  Maybe we should have a passwd-style database, with the fields
seperated by a field seperator (in unix passwd file, ":").  I personally
hate having to line everything up on the columns, I just did it to be
compatible with Challenge #25.

> Agreement on non-redundancy of info in separate files.

I see then that we do agree.

> Will extended system information require a special data format the way
> basic generation does?

I didn't think so, I just considered it "extra color" to throw in to the
.expand or .text file.

> ?World maps? in the extended file? Ah, one of your dreams...but how?

I envision having a program that, given a UWP, generates terrain,
weather, ocean currents (or glacier flow :-), demographics maps, etc.  I
should probably look at Grand Survey/Grand Census before I embark on
this.  It would be nice to know what a world looks like.  Long ago I
generated a quarter-subsector's worth of systems with a home-brew system
similar to Book 6 (which wasn't out yet).  I had detailed maps of all
the important worlds, moons, etc.  I was really proud of it.  For me,
maps really add to the experience.

> Have you seen Traveller's Digest?  They print subsector maps that are also
> a good format for output.

No.  I'd like to.  I better visit the Military Corner (local gaming
store) this weekend.  Looks like I'll have to shell out bucks for
Challenge, Traveller's Digest, and Grand Survey/Census, eventually.
Yuck, credit cards are nearing critical mass, almost ready to
gravitationally collapse and begin fusion...

> The routine 'upstr' is missing from mapsub and bzero is declared twice in
> gensec. (My compiler didn't have it--stupid PC software.)

Yeah, I added one in of my own, and made bzero conditionally compile, too.

> I don't need the file system.c.  I printed out the whole thing before
> breaking it into little pieces, and I don't like their code anyway.

Okay, I won't send it.

- --

To: James Perkins
Subject: Sector database
From: Fred Schiff

Fine. Send out the program with appropriate copywrite notices.

I have no problem with coordinating discussion, except that I am
graduating in May so we'll have to work fast. Plus I really don't
know how to handle such a task. Youv'e done it before obviously, so
how about some advice?

I do not live in the UK. I'm attending school at the State University
of New York at Binghamton. I got rid of my .sig by accident a few weeks
ago and didn't get around to putting another one in. UK indeed!!

You may want to wait on Grand Census/Grand Survey. The Digest people are
coming out with a new combined edition called, I think Grand Design, or
some such, in May or June.

I've determined that stars should not be in basic generation; there not really
necessary, you only need to know the tech level and gas giant prescence if
you only want the mainworld. I think GDW put them in because they had the
information, (which strikes me as unfair since the list didn't have the names
of the systems).

I do not have a copy of our messages on this computer. I sent them to another
computer, so in order to send them somewhere I would have to download them &
then upload them. I'm not a very organized person. Sloppy Oscar is me.

If the database uses a separate program for output formatting, it is perfectly
ok for the database to have :: separators between fields.  It makes a bit more
sense also since the first round at the output programs may be awk programs.
(If we find someone proficient in it)  Someplace I have a reference to an
article in Software about an awk database: it built a directory and a bunch
of commands for your database in such a way that you used the names of the
fields in your commands, and the commands translated them to the appropriate
#. And no I can't find it since its at home (home, home--Binghamton is similar
to Purgatory) under a foot and a half of accumulated computer papers and
photo copies.  The program allowed database function to filter into each other
(we can't with ours--we've got comments imbedded) but required a special
command to actually change the database.

If we have a separate file (.text) for commentary, then wouldn't the .expand
file have a passwd type format as well. Unsure of this. Hmmmm...maybe it just
makes it easier with a .text and .expand file.

Do you have animal encounter table software? Or character generation software?
I got 1 (one) (single) response. Fella said, "If you find any of these coult
I have some too?"

I'm unsure of the output format for expanded system generation. The St program
(which I never compiled) is missing some things, is somewhat unclear, and the
Ref's manual rules are a little unclear about some stuff. ie. if I get a
captured planet with a deviation of 0 what does that mean?, since type O & B
and size Ia & Ib stars are not generated, should star generation be part of
gensec (man with editor can change course of turtle island, eh kee-mo-sabi?),
how exactly do I determine where mainworld goes - there are available orbits
and the planet can go around the far companion.

Ugh. Its big really big. And you thought a walk down to the drugstore was a
long haul, but let me tell you....Ok I live in New York, where do you live?

- --

To: Rob Miracle <rwmira01%ulkyvx.bitnet@RELAY.CS.NET>
Cc: Fred Schiff
Subject: Re: sector.c
From: "James T. Perkins" <jamesp%dadla.la.tek.com@RELAY.CS.NET>

> James,
>   I took the liberty of taking your program 'sector.c' from one of the bundles
> and upgraded it to be compatible with MegaTraveller.  It now outputs the data
> in a format that is compatiable with the Spinward Marches Sector listing in th
   e
> back of the MegaTraveller Imperial Encylopedia and compatiable with my sector
> display program, which I intend to distribute soon.  More on that later.  I am
> going to send it back to you for your approval since it is your program.  Don'
   t
> get mad at me for changing the ways that you did somethings.  I did so because
> Turbo C 2.0 groaned at me about a few of them.

Hello Robert! Boy, you've been busy.  So has another listee, Fred Schiff
(vu0141@bingvaxu.cc.binghamton.edu).  Like you, he's redone the gensec
and also the mapsub program to be MagaTraveller-compatible.  I've Cc'ed
him on this message to keep him up-to-date, and I'm keeping all this
discussion online so that when the (new) topic coordinator can start, I
can forward it to him.

However, Fred's format and coding style is much more similar to the
original gensec program.  He and I have discussed a general dislike we
have for a couple parts of the MT Spinward Marches Sector Listing
format, and have been discussing how best to store sector data at
several levels of detail (UWP data, textual annotation, expanded system
generation, trade routes, etc).

I understand, I never wrote that code to be really, really portable.

>   This should be compilable on VAX/VMS C, Turbo C, and Sys V C with no
> modifications.  (I haven't tried Sys V or BSD, but it is pretty straight
> forward and I changed the srandom and random defs to make BSD the exception.
> Turbo C didn't like it in the original program.  I gather that you have 4.2 BS
   D
> there, so you can test it and make sure it still works :-)  I will try to test
> it on one of the AT&T 7300's running Sys V as soon as I can.

Actually, 4.2 has gone the way of the dynasoar :-) around here.  We're
running 4.2BSD, Ultrix 2.1 (mostly == BSD), and SunOS 4.0.

>   I will probably post my Sector Display program soon.  I have to clean it up
   a
> bit.  It uses the sector format given in MT:Book 3 for the Spinward Marches
> with the following exceptions.  A 15 byte system name is included between the
> hex id and the UWP.  Byte 5 is used by my program to indicate that an
> additional data file, with information specific to that system can be found
> (filename is hexid.HEX where hexid is the 4 digit hex location).  The hyphen
> between the UWP and the Tech Level was removed (I didn't type it in when I was
> entering the Spinward Marches data).  Trade Codes are case sensitive and begin
> immediatly after the base code.  There is 15 bytes allocated for that.  Next
> comes the Travel Zone code, population multiplyer, planetoid belts, and gas
> giants.  Next is the Alliance code (case sensitive) and the System Star Data.
> The only spaces that are included are in column 5, if no * is present, spaces
> fill the planet name.  A space is between the UWP and Base Codes.  Spaces
> seperate the Trade Classifications from each other, but not the rest of the
> data. and likewise for the Star Data.

Stylistically, Fred and I have settled on a format as follows:

System_Name_______ HxID CSAHPGL-T B Trade_Codes____ MPG Al
Unnamed            0102 C958366-8 S Lo Ni           702 IM
Unnamed            0107 C68698C-A S Hi              305 IM
Unnamed            0201 C764557-A M Ag Ni           004 IM
Unnamed            0205 A200000-F   Lo Ba Ni Va     204 IM
Unnamed            0307 B646843-5 A                 504 IM
Unnamed            0407 E8A7542-4   Ni              904 IM
Unnamed            0504 A6668AE-7                   514 IM
Unnamed            0505 B462589-9   Ni              912 IM
Unnamed            0607 B74587A-8 N                 124 IM

Note that for brevity, the Star Types/Sizes are not included.  They aren't
functionally useful in any that Fred or I can determine.

>   The program reads this file and asks for your starting location.  It then
> displays a hex map, with you world in the center and all surronding worlds and
> their UWP.  It then ask for your destination and tells you about it, displays
> any specific data (* in column 5) and the gives passenger and trade informatio
   n
> going to that world.

That sounds neat!

>   Now the bad part, it is written in Turbo Pascal V4.0 or V5.0.  It requires
> at least 640X400 resolution meaning you need an AT&T PC6300 or a PS/2 or PC
> with a VGA card.  Do you think there will be an interest in it?  Also, do you
> expect that GDW will get upset?  I know TSR would sue so fast it would make ou
   r
> heads swim.

Hmmm... it would also run on a Sun 386i, like we have here, if it's
UNIX-compatible.  The Sun does VGA and CGA.  But I don't know that Suns
have Pascal support; I don't think ours do.

As for GDW getting upset, I wouldn't pretend to know.  I suggest you
write them a long letter or figure out how to call them.  It's really
important to let them know what you're doing, especially if you're going
to sell the software for profit.  I suspect that GDW would get fairly
upset about the Spinward Marches data itself.  Pick up a copy of
Challenge magazine and browse through the MegaTraveller publishing data
to find contacts within GDW.

There is already a volunteer for a topic coordinator for the Star
Systems discussion, whom I haven't gotten back to yet.  I think that
more discussion, idea brandishing, etc. would be very valuable on this
topic, and I'd like you to lobby for what you think might work best.
The more ideas we get for data representation and
generation/display/maintenance implementations, the better off the final
products will be.

- --

To: Fred Schiff
Subject: Re: Sector database
From: "James T. Perkins" <jamesp%dadla.la.tek.com@RELAY.CS.NET>

> Fine. Send out the program with appropriate copywrite notices.

Will do.  You should've gotten a message I'm sending to another fellow who
also beat my gensec program into MegaTraveller submission (hmmm... kinky
software... pasta, anyone? :-).  Everyone has a pet format for a database.
It's probably a good time to try to come up with something universal.
I've also had an offer to coordinate the star database/generation discussion.
Yeah!  He'll be the third person to know, though.  It may take a couple weeks
to get that functioning.

> I have no problem with coordinating discussion, except that I am
> graduating in May so we'll have to work fast. Plus I really don't
> know how to handle such a task. Youv'e done it before obviously, so
> how about some advice?

That's why I'll choose him before you.  Hope you can find email access
wherever you go to.  It'll be more painful than usual to lose your membership.

Not in the UK? Oops! I thought the name sounded UK-ish.  I live in Portland,
Oregon, and commute to Beaverton to go to work.  Kind of a far piece to meet
for lunch.

I just heard this weekend that Grand Survey/Census are out-of-print, and that
a MegaTravellerized version was in the works.  Wonder when we'll see
anything.

I agree with you about the non-necessity of stars in the basic generation.

> If the database uses a separate program for output formatting, it is perfectly
> ok for the database to have :: separators between fields.  It makes a bit more
> sense also since the first round at the output programs may be awk programs.

Good comment.

> (If we find someone proficient in it)  Someplace I have a reference to an

I'm fairly proficient in awk.

Sounds reasonable for the .expand file to be : seperated.

> Do you have animal encounter table software? Or character generation software?
> I got 1 (one) (single) response. Fella said, "If you find any of these coult
> I have some too?"

Nope, I don't have any.

> I'm unsure of the output format for expanded system generation. The St program
> (which I never compiled) is missing some things, is somewhat unclear, and the
> Ref's manual rules are a little unclear about some stuff. ie. if I get a
> captured planet with a deviation of 0 what does that mean?, since type O & B
> and size Ia & Ib stars are not generated, should star generation be part of
> gensec (man with editor can change course of turtle island, eh kee-mo-sabi?),
> how exactly do I determine where mainworld goes - there are available orbits
> and the planet can go around the far companion.

Deviation of 0?  I either reroll or count the captured panet as a moon (or if
too large, as the planet, and make the original planet a moon).
I think star generation belongs in a seperate, expanded system generator.  I
agree that the Ia, Ib, O & B should not be machine generated -- it should only
be assigned by the Ref.  Mainworld is either the planet with the highest pop,
or if it's premade it is placed in the innermost habitable orbit.  If there's
lotsa gas giants, it becomes a moon of the GG in the habitable orbit.
Probably those are my rules.

Gotta run, get some work done.

- --

To: James Perkins
Subject: Re: sector.c
From: Rob Miracle
Cc: Fred Schiff

Ahhh, and after all that hard work... :-(  (Just Kidding)
I would like to see the star data there as I, for one, use it.  I use it to
determine the orbits of the worlds etc.  Eventhough, Dinomn (or Dinome) can not
exist by the rules.  I am sorry, you just can't have a type 6 atmosphere when
you are in orbit one around an M6 Dwarf, even though the rules say you can, it
is just too darned cold (Something like 79 degrees Kelvin), Yes Virginia,
Oxygen does freeze.  But, if you are going to do any amount of intra-system
travelling, the Star info is the beginning.

I personally would like to see it taken even farther, but it becomes a data
nightmare to manage.  For simplicity sake, we need to keep what ever format
ASCII and under 80 characters and one line per system, but I would like to code
in some orbital information as well.  (My I ask alot).

I would like to see a column somewhere where I can put my * so that I know to
look for a file with that hex id for a filename.  It is a very simple way of
maintaining library information on a given world.  The new format is quite
accpetiable.  (Now I just have to convert my MARCHES.DAT file to the new format
:-(  I guess I will write a program to do it... :-) )

- --------

End of STAR SYSTEM DIGEST

The Traveller Mailing List is a courtesy of James Perkins and Tektronix, Inc.
All opinions and material above is the responsibility of the originator.
Send Submissions To: @RELAY.CS.NET:traveller@dadla.LA.TEK.COM,
	uunet!dadla.la.tek.com!traveller, or traveller@dadla.la.tek.com
List Administrator: traveller-request@dadla.la.tek.com

-------- End of TML Messages --------

